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Remarks 

Claims 45-88 are currently pending in the subject application and are presently under 
consideration. 

Favorable reconsideration of the subject patent application is respectfully requested in 
view of the comments and amendments herein. 



I. Rejection of Claims 45-88 Under 35 U.S.C. S102(e) 

Claims 45-88 stand rejected under 35 U.S.C. § 102(e) as allegedly being anticipated by 
BCreidler, et al. (US 6,975,913 B2). This rejection should be withdrawn for at least the following 
reasons. Kreidler does not anticipate each and every element set forth in the subject claims. 

"A claim is anticipated only if each and every element as set forth 
in the claim is found, either expressly or inherently described in a 
single prior art reference." Verdegaal Bros. v. Union Oil Co. of 
Califomia, 814 F.2d 628, 631, 2 USPQ 2d 1051, 1053 (Fed. Cir. 
1987). "The identical invention must be shown in as complete 
detail as is contained in the... claim." Richardson v. Suzuki Motor 
Co., 868 F.2d 1226, 9 USPQ2d 1913, 1920 (Fed. Cir. 1989). 

The subject application relates generally to industrial control systems, and more 
particularly to an architecture that can facilitate web-based implementation of HMIs {see e.g., pg. 
8, 11. 23-26) in an industrial automation environment {see e.g., pg. 10, 11. 27-28). Moreover, the 
HMI can be rendered at a central location (e.g., at a server or web server) and delivered to and 
displayed by browsers operating on client devices {see e.g., pg. 9, 11. 30-31) over a browser 
session connection previously established. Thus, the client devices can be zero-install clients 
that run a standard web browser, but without the necessity for any additional application-specific 
software or higher end hardware. As such, a potential reduction in installation or upgrade costs 
can be obtained {see e.g., pg. 3, line 22 - pg. 4, line 2). 

In particular, independent claim 45 recites, in part, "means for interfacing a server 
component by way of a network to a set of client devices associated with an industrial 
automation environment, wherein at least one device included in the set is a zero-install client 
device with respect to rendering a browser-based HMI." For example, a client device can 
display the browser-based HMI via a standard web browser and, as a zero-install client device. 
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can do so without any other application-specific software to manage, format, configure, or 
determine aspects of the browser-based HMI. Such differs firom existing HMI systems since no 
additional client-side application-specific software is required to render a browser-based HMI, 
such components need not ever be modified in the event of an update to the HMI architecture. 
Independent claim 45 also recites, in part, "means for establishing at least one persistent browser 
session over the network with at least one browser running on the at least one device included in 
the set of client devices." For instance, the persistent browser session can be asynchronous 
and/or continuous, and thus can push or pull data and fiirther, need not be broken and re- 
established following a response. This differs fi-om conventional HMI systems that employ 
browser-based communication to propagate information in that such conventional system only 
operate by way of well-known query-response models and terminate at the completion of each 
response cycle, and therefore must be re-initiated for each query. Independent claim 45 fiirther 
recites, in part, "means for transmitting the browser-based HMI over the network by way of the 
persistent browser session to the at least one browser." For example, processing and other 
determinations regarding the browser-based HMI can be performed at a central server and 
propagated to zero-install clients, thus reducing costs for installation, maintenance, and/or 
updating. In contrast, existing HMI systems employ application-specific software to render the 
HMI at the client device (e.g., there is no transmission of the HMI to the client device). More 
specifically, the art of record fails to disclose or suggest each and every element of independent 
claim 45, as well as similar elements recited in independent claims 48 and 73. 

In contrast, Kreidler relates to aggregation of data fi-om a plurality of client automation 
systems into a central database structure and management of the data. While Kreidler does 
contemplate leveraging web browsers to effectuate communications between a client and a host 
(col. 5, 11. 24-34), Kreidler fails to anticipate claim 45 in at least three distinct ways: 

First, Kreidler does not disclose or suggest "means for interfacing a server component by 
way of a network to a set of client devices associated with an industrial automation environment, 
wherein at least one device included in the set is a zero-install client device with respect to 
rendering a browser-based HMI.'" The Office Action dated July 9, 2010 asserts that the "Zero 
install client device in the disclosure is not entirely "zero install" as is renders some tools from 
the server/host device that are associated with the HMI". In particular, the Office Action asserts 
that an operating system and a web browser are installed on the client device. However, the 
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operating system and the web browser are not application specific software. They are general 

software installed on the client that are independent of any unique requirements associated with a 

specific web based application running on the server. Pages 3, lines 18-32 of the specification 

provide clarification regarding the meaning of the term "zero-install client". More specifically, 

this paragraph states: 

The basic premise of a web-based application is that all (or at least 
most) of the application-specific sofl:ware is installed and runs on a 
relatively small number of server computers, while the client 
computers that are used to access the provided functionality need 
only have the standard operating system and a web browser 
installed on them. As both the operating system and the web browser 
are typically installed on the computer by the vendor, the purchaser 
needs to do very little (if any) configuration to make these computers 
functional. For web-based applications, which require no 
application-specific client-side software, this results in a so-called 
"zero-install client." Installation and configuration of the 
application-specific software (in our case, the web-based HMl 
software) — both the initial installation/configuration and subsequent 
upgrades/reconfigurations — need only be done on the significantly 
smaller number of server computers. Furthermore, since the client 
computers run only a web browser (as opposed to the traditional large, 
complex, computationally intensive and "resource hungry" 
application-specific software), significantly lower-cost computing 
hardware can be used. 

In stark contrast Kreidler expressly teaches away from such a solution. In particular, 
Kreidler requires that a machine handler be installed and activated on the client (col. 5, 11. 
41-45; FIG. 4, element 56). The machine handler is necessary to interpret downloaded content 
from the server (col. 5, U. 54-60). Hence, Kreidler explicitly requires application-specific 
software (e.g., the machine handler) to exist on the client in order to interact with content from 
the server. Thus, Kreidler specifically leads away from a zero-install client device with respect 
to rendering a browser-based HML The Office Action cites column 2, lines 42-56 as teaching 
this feature. However, this section of the reference merely discusses using a connection of a 
public network to communicate data between the host and an automated machine tool. This 
section is silent regarding a zero-install client device as featured in the subject claim. 

Second, BCreidler is silent as to "means for establishing at least one persistent browser 
session over the network with at least one browser running on the at least one device included in 
the set of client devices." While Kreidler does indicate a browser can be employed to 
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communicate with the host, such is disclosed in the context of downloading web pages from the 
host and transferring user data (cited col. 5, 11. 26-34). Such elements are typically achieved by 
way of a request by the browser followed by a corresponding response from the server, after 
which communication is immediately terminated. There is no disclosure in Kreidler that can be 
pointed to that can sustain an anticipation rejection with respect to "at least one persistent 
browser session," as BCreidler is void of any such feature or suggestion thereof 

Third, BCreidler does not disclose or suggest "means for transmitting the browser-based 
HMI over the network by way of the persistent browser session to the at least one browser." In 
fact, Kreidler discloses that data (e.g., machine tool source code), formatted in a manner that the 
client side machine handler can interpret, is transmitted to a machine handler interface, which 
forwards the data to the machine handler, which is then interpreted and delivered for display at 
the client HMI. It is therefore readily apparent that Kreidler does not relate to transmitting the 
browser-based HMI over the network, but rather discloses interpreted data transmitted from a 
client-side machine handler to a client-side HMI device (cited col. 5, 11. 55-67). Appreciably, 
such is not disclosed to occur over the network, much less by way of the persistent browser 
session. In other words, Kreidler discloses that raw automation data is processed on the client to 
generate an HMI that is then displayed on the client. Accordingly, no fransmitting of the HMI 
occurs. Furthermore, cited col. 8, 11. 1-8 merely discloses an interaction of a user with the host 
through the browser. This section fails to disclose that the interaction is through a persistent 
browser session. 

In addition, independent claim 48 and 73 recite, "a communication component 
configured to interface via a network to a set of client devices associated with an industrial 
automation environment, and that initiates via the network a persistent browser session with at 
least one browser operating on a device included in the set of client devices" and ''transmitting 
the browser-based HMI over the network by way of the persistent browser session to the at 
least one browser," respectively. Kreidler fails to anticipate or suggest these features for at least 
the reasons detailed supra in connection with independent claim 45. For at least the foregoing 
reasons, claims 45-88 are believed to be allowable over the art of record, and this rejection 
should be withdrawn. 

Furthermore, dependent claims 47 recites in part, "maintaining the at least one persistent 
browser session in an asynchronous and continuous manner." Similarly, dependent claim 53 
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recites, "the communication component maintains the persistent browser session in a continuous 
fashion while the browser-based HMI is displayed by the device," dependent claim 54 recites, 
"the communication component maintains the persistent browser session in a continuous 
fashion independent of completion of requests or responses" and dependent claim 75 recites, 
"maintaining the at least one persistent browser session in a continuous manner." The Office 
Action points to column 2, lines 42-49 of Kreidler, which discloses "Data collection can be done 
in either synchronous or asynchronous fashion" as support for rejecting these claim. 

However, disclosing communication can occur in either synchronous or asynchronous 
fashion does not disclose or suggest communication in a continuous fashion. In fact, 
asynchronous data collection suggests either large batch data transmitted periodically or sporadic 
event-oriented transmissions, neither of which suggests maintaining a persistent browser session 
in an asynchronous and continuous manner. Furthermore, what Kreidler discloses as being 
asynchronous relates to data collection, whereas claim 53 expressly recites "in a continuous 
fashion while the browser-based HMI is displayed by the device." Kreidler does not disclose or 
suggest said data collection (e.g., the communication that can be asynchronous) occurs while the 
browser-based HMI is displayed. For at least the foregoing reasons, this rejection of claims 47, 
53, 54, and 75 should be withdrawn. 

In addition, dependent claim 62 recites, "fiirther comprising a memory remote from the 
device that stores a library or profile associated with the browser-based HMI." The Office 
Action alleges these features are disclosed at column 3, lines 18-24. However, the indicated 
portions detail a code specific to a machine tool that is used to identify data uploaded from a 
machine tool to the host. A machine tool is not the same as a browser-based HMI of claim 62. 
Accordingly, an identifying code specific to a machine tool is materially distinct from a library 
or profile associated with the browser-based HMI. For at least these additional reasons, 
dependent claim 62 is allowable for further reasons beyond those discussed in connection with 
independent claim 48 from which it depends. 
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Conclusion 

The present application is believed to be in condition for allowance in view of the above 
comments and amendments. A prompt action to such end is earnestly solicited. 

In the event any fees are due in connection with this document, the Commissioner is 
authorized to charge those fees to Deposit Account No. 50-1063 [ALBRP316US]. 

Should the Examiner believe a telephone interview would be helpful to expedite 
favorable prosecution, the Examiner is invited to contact applicants' undersigned representative 
at the telephone number below. 



Respectfully submitted, 
Ttjrocy & Watson, llp 



/Nilesh S. Amin/ 
Nilesh S. Amin 
Reg. No. 58,407 



TuROCY & Watson, llp 
127 Public Square 
57* Floor, Key Tower 
Cleveland, Ohio 44114 
Telephone (216) 696-8730 
Facsimile (216) 696-8731 
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